question: should we just accumulate all the extra fields from events into the message?
TBH, what I really expect here is to see the same extra fields I would get if I made a non-streaming request. Maybe we shouldn't accumulate all the extra kwargs from events, but only the ones that make sense (which are extra kwargs for the non-streaming case too).

• Does that make sense?
• Do we know which events are responsible for transferring the extra fields we would see in the non-streaming case?

I believe non-streaming requests already copy over these extra fields (the code I'm working with broke when we moved from non-streaming to streaming). I'm not sure exactly where that happens, though.

Sorry for the confusion! Let me explain what I'm seeing.
So in the non-streaming case, we have extra fields A and B, right? I'd expect the streaming case to have those same fields – no more, no less. But right now it looks like it might be getting more.
It seems like we're accumulating extra fields from all the events into the final message, including stuff from the message-stop event and other events that don't actually hold message data. I don't think that's what we want here – or am I missing something?

Also, could you share the SDK version and the requests you made for both streaming and non-streaming? That would be super helpful for figuring this out!

Would it be enough to gate this logic on the event.type?

I will have to dig up the version numbers and test cases later.

It'd be great to understand which particular events are responsible for transferring message extra fields. From the snapshots you've created for the test, I see that these are message_start, content_block_delta, and message_delta. We can potentially update kwargs only if the event is one of these as you mentioned. It would help us avoid filling up the extra kwargs of the final message with unnecessary data.
Also, I noticed that the same kwargs could be sent through different event types. For example, in your snapshot, message_start, content_block_delta, and message_delta are all sending the private_field extra field. Is that intentional?

P.S. I see that message_delta can send some fields which have already been sent by message_start, such as usage or context management fields, so we need to accumulate at least these two events. But I'm not sure about content_block_delta.